Go to the first, previous, next, last section, table of contents.

Automation of Units and Sides

Specifying the exact sequence of actions and their operands for every single unit would be mind-numbingly complex, and, for that matter, not very realistic either. Therefore, Xconq includes several levels of automation for human players.

The elements of automation are the task, the plan, the doctrine, and the strategy. These are related to each other by goals.

Tasks are single activities of a unit that require one or more actions to accomplish. Examples of tasks include moving to a given position, or waiting 15 turns to be picked up by a transport. Most of the commands that you give while playing actually set up tasks rather than individual actions.

A plan is the unit's object that expresses its decided-upon behavior. Elements of a plan include a type, possibly one or more goals, a task agenda, plus some assorted flags and properties. All units that can act and that are on a side will have a plan, while independent units that can do actions may have a plan that is preset by a scenario. Plans primarily govern individual behavior, in many cases allowing the unit to act on its own, without needing any explicit direction from the player.

The doctrine is the set of parameters governing how the side will play and how its units should work generally. For instance, per-unit doctrine specifies the point which a unit low on supply should start to look for a place to replenish itself.

The strategy and associated subobjects is what an AI uses to make all the decisions about what to do. This object is not directly visible, unless the AI is acting as your assistant and the interface includes a display of its strategy.

Of all these types of objects, only the doctrine can be manipulated directly; all others are implicitly changed as a result of player commands, which are different for each interface.

The Standing order command allows you to set up conditions for execution of tasks.

Using Doctrine

There is a doctrine for each type of unit on your side. Several types may share a single doctrine, so that changes to it will affect all types equally.

[more doctrine info]

Plans

A unit's plan must be one of the types listed here.

Tasks

A task has several standard properties and may have additional properties specific to the task's type. Xconq keeps track of how many times a task has been executed and how many times it has failed to execute a step correctly. For example, a movement task to a distant location may need to execute 100 times, but it will only fail if the unit is actually blocked from moving. If a task fails too many times, the plan or the AI may decide to remove the task from its agenda. If a task succeeds, it will always be removed.

Each task in a plan's task agenda must be one of the types listed here.

Standing Orders

Standing orders are basically a combination of a test or condition and a task to be performed when the condition is met. The textual form of the command is "if <type> <test> <task>", where <type> is a name of a unit type, <test> is some sort of condition, and <task> is a task, as described previously.

Possible tests include at location, in unit, and near location dist.

The at test applies to the unit if it comes to be in a particular cell, for whatever reason. The location may be either a comma-separated pair of coordinates, or the name of a unit.

The near test is similar to at, but you give an additional argument that says how close, in cells, the unit must be for the order to apply. For instance, a distance of 1 means that the order applies to units at the given location and to all adjacent units. This is useful if you want to have several kinds of units use a rendezvous point that is on a type of terrain that some of the kinds can't use, or if there are stacking limits and requiring all units to converge on a single cell would result in traffic jams.

The in test applies to the unit if it is an occupant of the given unit.

If a unit is already performing another task, it will ignore any standing orders in any location that it happens to be passing over; so it is not possible for the standing order to waylay the unit and send off doing something else. The unit must be under your orders ("passive" plan), not have any tasks on its agenda, and cannot be asleep or in reserve.

if armor in Paris move-to Antwerp

if bomber in London move-to 33,54
if bomber at 33,54 hit-position 34,60

The second example shows how you can use several standing orders together to route units around obstacles or dangerous areas.


Go to the first, previous, next, last section, table of contents.